1. Field of the Invention
This invention pertains generally to computer program configuration, and more particularly to an image network download system that is action tree-based.
2. Description of Related Art
Configuring the software in modern computers and computerized devices is becoming increasingly complex as the number of possible models, option sets and other variants increases. For example in supporting the sale of configured to order (CTO) computers the matrix of choices available for a given system, when considering the different foundation images and application image sets, could run up into the millions of different image sets, any of which would need to be copied to the hard drive of the computer.
Typically, the choices involve a small number of foundation image sets which relate to the specific hardware in addition to a collection of application modules which could be installed to run on those computers.
This plethora of image choices is a burden not only in the production environment, but in other areas as well, such as within engineering, testing, quality assurance, service and so forth wherein the software and/or applications must be configured or reconfigured to any of the present or previous configurations available from manufacturing. To create these hard drive images, modular image download programs have been created which load a foundation image along with a predetermined set of application module images which are to be installed on the hard drive. For any one release of hardware and/or software there may exist a number of different varieties of the imaging program, for example versions for the Factory, Engineering, Test, Quality Assurance, Service Department and so forth.
Typically, in the CTO environment the determination of what is to be loaded to a given system is determined at least partially, if not fully, in response to the information which is contained within a desktop management interface (DMI). The DMI is an area in the hardware of a computer device in which a string, referred to herein as Mcode, is contained. The DMI also includes a section referred to as UUID which provides a unit serial number for the hardware. The bits of Mcode retained in the DMI indicate information about the device, such as hardware characteristics along with what foundation image and other modules are loaded, or are to be loaded. Since Mcode is not contained on the hard drive, the hard drive may be repartitioned and formatted as necessary without affecting the state of the Mcode. Mcode is written to the DMI before the downloading of images onto the hard drive.
About a decade ago the industry primarily relied on the use of batch files for downloading images to the hard drive of a new system. The batch files used multiple data sources and severely lacked flexibility making it difficult or even unrealistic to consider supporting a large number of different image sets. In addition any changes to the configuration had to be carried out across multiple data sources and batch files, wherein the process was labor intensive, error prone and tedious.
More recently modular network imaging was introduced which relied on a single data source and a suite of programs written in a high-level language that typically leveraged the functions made available within the application programming interface (API) of the operating system. The download process was performed in response to the execution of separate executables. One such download configuration program utilized at Sony is referred to as MINDS (Modular Network Download System) version 1 which was utilized in combination with a program toolset known as Pacific Tools.
It should be appreciated that the ability to build a system with different foundation and application modules is necessary to support the sale of configure to order (CTO) computers which offer the customer different sets of software. An example is that of allowing the customer to select the word processing and multimedia software to be loaded on their machine. The process of taking a foundation image and adding modules to create an image is known herein as Sony Modular Technology. The benefit of this technology is that an exponentially increasing number of images can be offered to the customer. For example, letting x equal the number of foundation images, y equal the number of modules, and z equal the number of unique images that can be offered; the equation z=x2y describes the size of the number of different images. By way of example with twenty three foundation images and thirty three modules the number of unique possible images that could be offered to customers is over eighty seven billion, although typically only a subset of these are offered at any one time. A manufacturer having the capability to offer and support a large number of possible images provides a competitive advantage.
The life cycle of an image can be considered to have a number of phases. (1) Planning—Program management decides what software will be placed on a particular type of PC. (2) Development of image components—Integration of software into foundation images, modules, and recovery components. (3) Testing image components—Testing of integration, software, and various CTO options. (4) Releasing and delivering image components—Sending components to production sites. (5) Support—Supporting products via sustaining, refurbish, and repair.
Typically, the most technically challenging stage of image life cycle is development, while the most labor intensive is testing. In either case systems are frequently re-imaged with new software. One of the primary reasons for reimaging is to test the various CTO options. Another reason is to return the system to an “as-shipped” factory state.
Due to this need to frequently re-image systems, especially during testing, the process of imaging has historically been a bottleneck due to the amount of time it required. A system is unusable until the imaging process is complete. Furthermore an engineer has to spend time to image the system by providing input or swapping CDs, in what is typically a very time consuming process that is prone to errors. Thus the process of imaging a system requires the time of an engineer and results in the system being unusable while imaging takes place. It will be appreciated that many benefits can be derived from minimizing these times to reduce or eliminate the bottleneck.
There have been attempts at a solution, but all fall short in terms of time requirements and flexibility.
Early imaging solutions were manual processes to image the systems using CDs that were called “Install CDs”. This process was relied-upon before the development of the first modular imaging network download solution, such as MINDS version 1. Install CDs typically utilized MS-DOS as the operating system and were on CD (as opposed to a faster medium), wherein it commonly required an engineer about a half day to image a system. This process also had the additional cost and delay of having to replicate CDs before systems could be imaged, increasing the bottleneck even further. Furthermore, the selection of options was very complicated and limited.
At the time the first modular imaging network download solution (i.e., MINDS version 1) was developed a new method was devised to image systems. This method provided a manual process that imaged a system over a local area network (LAN) as opposed to CDs. While MS-DOS was still the operating system used, this switching from CDs to a LAN decreased the total time to image a system from half a day to a roughly three hours. While the speed was increased, the various CTO options were not available to test.
Furthermore, since this process was performed manually there was a fundamental weakness in the imaging process, making it difficult to image a system the same way twice. This lack of consistency arises from having to manually perform many steps in the imaging process and posed a significant problem. Eliminating the need to perform these manual steps would eliminate the inconsistency.
The MINDS version 1 imaging software was created to leverage the power of new advancements in PCs and resulted in a process that was able to image a system in about an hour while only requiring about ten minutes of engineering time, which was a substantial improvement over the use of installation CDs. MINDS v1 also was configured to interact with a Software Management System (SMS) database to allow for testing of CTO options for the first time and had the ability to upload images to the LAN as well. The deployment of MINDS v1 meant that images were uploaded and downloaded in a consistent manner for the first time, which also increased the accuracy of testing.
Although the current MINDS v1 program provided a number of advantages, as would similar configuration programs used in the industry, it still suffers from a number of shortcomings which reduce the flexibility of the download process and complicate user interaction.
Accordingly, there is a need for enhanced software within a modular network download system which provides added flexibility and ease of use, the present invention fulfills those needs as well as others.